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ABSTRACT 

Educational development requires management # Which is 
tasically decision-making based upon inf ormation. information must be 
processed, involving movement from its source, analysis, 
transmission, storage, retrieval, summarization, transformation, and 
reporting. The regulation of. this process is the. purview of the 
information management system (IMS) , an essential ingredient of 
educational development: The characteristics of an effective IMS are: 
relevancy, timeliness, accuracy, comprehensiveness, conciseness, 
accessibility, and inexpensiyeness. Difficulties involved in 
establishing an IMS in educational development projects stear frcm the 
high ccsts involved, the lack of a stable setting in which to place 
the system, the changing needs for information, and the danger of 
inundation by information overload. .Such a system is possible, 
however, if developers: 1) select the decisions which need to be 
made; 2) identify the needed information and its sources; 3) choose 
the proper means of information processing; 4) estimate costs and 
curtail the system to match cost constraints; and 5) implement and 
revise the system. . (PB) 
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Instructional developers "have never denied the eclectic 
nature of their field. To borrow Singh's remark about systems 
.analysis, development "dees not hesitate to make any branch of 
science carry grist to its own mill." (1) This phenomenon has 
been nowhere more evident than in the area of management theory 
and practice. 



MANAGERS AND DECISION-MAKING. It is axiomatic that a manager 
is foremost a decis ion -maker . Confronted by a given set of 
circumstances, he formulates a response, which, he hypothesizes, 
will bring optimum results. If, in fact, the results are 
disappointing, he will then select different alternatives so 
as to amend the results. In this respect, effective decision- 
making is a cybernetic loop, a succession of adjustments, 
large or small, tending toward increasingly more satisfactory 
p% results. 

{/^ Development- -instructional or otherwise- -does not merely 

happen; it requires management. The same cybernetic decision 
— process of management comes into play in development, and this 

o 
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pertains whether the development effort is limited to one 
teacher preparing the day's lesson or consists of a sizable 
team reformulating an entire curriculum- It follows irhat 
all developers are managers , and hence decision -makers . 



DECISIONS AND INFORMATION, Good decisions are based on good 
information. Forrester observes that "management is the pro 7 
cess of converting information into, action/ 1 (2) and he equates 
this activity with decision -making. To be useful in effective 
decision -making, information is required about the present 
state of the system, the desired state of the system, and tfre 
alternative means of getting from one to the other. Absence 
of the right information is probably the leading cause of 
failure in instructional development. 



INFORMATION PROCESSING. Information remains useless until it 
is processed, i.e., put into meaningful, usable form. Just as 
complex organisms cannot utilize nourishment directly, but must 
assimilate it, complex decision -making requires "digestion" 
of data** Information must move from its point of origin, must 
be obtained, analyzed, transmitted, stored, retrieved, sum- 
marized, transformed, and reported (Fig. 1). 



*The distinction commonly made in the literature between 
information and data is acknowledged. For purposes of this 
paper, data are regarded as bits of intelligence unprocessed 
for decision -making, whereas information consists of inter- 
pretations of data suitable for making- decisions (as well as 
for other purposes). The distinction, however, is not critical 
to most points made in the paper, and the two terms are used 
somewhat interchangably . 
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THE IMS. Information and information processing do not 
manage themselves —they too must be managed. This suggestion 
may raise images of "wheels within wheels," but there are 
sound reasons for paying attention to the management of in- 
formation. As t he-complexity of the developmental effort 
increases beyond the most elemental level (i.e., one developer, 
one client), the need to attend to information management, in- 
creases arithmetically or even exponentially (see Fig. 2). 

A valuable distinction for the developer is that between 
the .management information system (MIS) by which information 
is processed' and channelled to top management for action, and 
the information management system (IMS) in "which the flow and 
processing of information itself is the subject of the manage- 
ment effort. The two systems are completely compatable, and 
each is essential to the effective management of development 
efforts. The importance of the distinction lies in the 
necessity of attending to both kinds of endeavors, supplying 
proper information for management purposes and properly 
managing that information. 

The characteristics of an effectual information manage- 
ment system are known. Information is to be: 

1. Relevant (i.e., targetted to specific decisions) 

2. Timely 

3. Accurate 

4. Comprehensive 

5. Concisely packaged 

6. Accessible to those with right of entry 

7. Inexpensive. 
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These desiderata may be considered the goals of the IMS. Un- 
fortunately, the goals are in many cases at variance with, 
each other. For instance, timely or current information may 
prove to be inaccurate due to the lack of time to verify it. 
Comprehensiveness and conciseness are antagonistic qualfties. - m 
And cost considerations mitigate against other desirable 
characteristics of the needed information. 

Trade-offs represent the only solution; the task of 
managing information suddenly appears more demanding than it 
might have at first. 

COST OF INFORMATION PROCESSING. All information bears a price 
tag, unusually high. Information processing can cut deeply 
into scarce developmental resources. Administrators who view 
development as a sonewhat unjustifiable luxury on the edu- 
cational scene will probably regard the additive cost of in- 
formation processing with even less joy. 

Only a modicum of the "nice -to -know" information may be 
realistically obtainable within the range of resources normally 
available to a development project. Extraordinarily hard 
choices between high-cost-high-gain information and low-cost- 
low-gain information may have to be faced. Inevitably, there 
seems to be a dearth of low-cost-high-gain information! 

OTHER TYPICAL PROBLEMS. Additional problems in managing in- 
formation are created by the nature of development itself: 
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1. Techniques of information processing flourish in a 
corporate environment in which needs, sources, channels, and- 
so on remain relatively stable over time. This is much less 
the case in developmental settings in which change is the rule 
and the customary technology of information processing- (e.g., 
computers) lacks the adaptability to match the dynamics of 
development. This circumstance argues for less complex, more 
responsive technologies for processing information in* all but 
the most extensive development projects. In Fig. 3 exemplars 
of more and less .powerful*, more and less adaptable techniques 
are shown, the least powerful (most adaptable) are recommended 
for elementary development efforts; the middle range is sug- 
gested for development as generally practiced, and the upper 
range is reserved for only the most arduous and long-term * 
projects. 

2. A similar problem lies in the fact that informational 
needs change as development proceeds. During the early stages, 
team members will need quite different kinds of information 
than during later stages. Planning decisions, as defined by 
Stuff lebeam et al., (3) predominate in the early phase and 
demand information unlike that required by structuring de- 
cisions, recycling decisions, and implementing. decisions 
which follow (see Fig. 4). The situation is further compounded 
by transience among personnel, particularly characteristic 

of development in higher education, which disrupts information 
flow and requires frequent orienting of new personnel to the 
information system. 

3. "Information overload" may plague decis ion -makers . 



V 
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In the. classic situation, two executives stand bewilderedly 
before a massive computer, and one says, "What it comes down 
to, is this thing is capable of telling us a lot more than 
we really want to know. 11 As projects move upward in com- 
plexity, the sheer volume of newly created information, the 
demand for previously unneeded information, and the physical 
remoteness of niany of the participants may overwhelm the un- 
prepared developer. Unless a workable information management 
system is hurriedly erected, the project may collapse. This 
critical stage often occurs just beyond the threshold at 
which most developers now stand--the transition from projects 
focussed on a single unit or course to multiple -course pro- 
jects, with a concommitant increase in team membership and 
complexity. 4 

RELATE. These problems, and the pleasures of finding viable 
answers to some of them, are aptly illustrated by Project 
RELATE, one of the most, ambitious development efforts under- 
taken at Indiana University since the creation of an Instruc- 
tional Development Department in 1968. RELATE is an acronym 
for REading and Language Arts Teacher Education. It consists 
of a sizable portion of the pre-service elementary education 
major's block of professional courses (24 semester hours in 
all, including student teaching) . At one time or another, 
representatives from Reading., Elementary Education Language 
Arts, Linguistics, and Educational Psychology have held mem- 
bership on the team, as has one member of the public school 
.administration. The project also has an inter-campus and 
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in^~- institutional flavor, with input received from nine 
campuses in Indiana and use of the product currcfirtiy • on four 
campuses of tht nine. 

Shortly after the project's inception in the spring 
of 1970, teams were organized along the lines of a ''specialize 
model (Fig* 5) in which each team applied its specialty to 
each of the units as they were passed from team to team, as- 
sembly-line fashion. Almost immediately, the project was 
inundated with information as the teams attempted to communi- 
cate with the directors and with each other, and the directors 
sought to communicate with the teams and with various other 
"audiences." Numerous early attempts to~ expedite -the flow of 
information (meetings, memos, speed mailings, installation of 
a copy machine for exclusive use of the project) met with 
mixed success. After some months and a few critical moments, 
team membership was pared back, teams were re-organized some- 
what along the lines of the "generalized" model (Fig. 5) and 
better match between needs and processing techniques was 
achieved. Productivity increased with each improvement, and 
Project RELATE was able to claim "mission accomplished" in 
slightly over three years. Not all the credit can be claimed 
by the IMS for these results, but unquestionably the emergence 
of more effective communications made a significant contri- 
bution to productivity and laid the groundwork* for effectual 
project management. 

DEVELOPMENT OF AN IMS. The steps in establishing a system 
for managing information may appear deceptively easy (Fig. 6). 
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They are not easy, but on the other hand, they are attainable. 
Some notes on each: 

1. Select decisions . Perhaps the most intriguing step, 
this is certainly the most neglected. The Stuff lebeam de- 
cision matrix referenced in Fig. 4 serves as a useful base for 
this step of the process. Stuff lebeam and his colleagues 
remark : 

Within each decision-making setting 
are literally thousands, of specific 
r _ educational decisions, all different 

from each other. Unless ways can be 
found for grouping these individual 
decisions, it will be necessary to 
contrive a different design for every 
conceivable decision. (4) 

This matrix represents their solution, the foundation of 

the well known CIPP model.* 

In Project RELATE, specific decisions gradually evolved 
over time, as shown in Fig. 7. These decisions have a ready 
generalizability to most, if not all, instructional develop- 
ment. Note that each decision subsumes a large class of 
sub-decisions which are commonly encountered by developers. 
Much of the art of development lies in keeping these in focus 
as the project proceeds. 

The tightest possible decision design also calls for 
specifying -each plausible condition, or status, which could 



*As the reader has no doubt noted, the management in- 
formation process bears a strong resemblance to present-day 
concepts of evaluation. Most of the statements made in this 
paper could be made of evaluation just as readily, and the 
evaluation literature will continue to make an invaluable 
contribution to the developer-manager. 
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conceivably come to bear upon a given decision, and stip- 
ulating the appropriate- course of action for each* 

2. Identify appropriate information . At this step, 
information needs are identif iecH for each decision. This pro- 
cedure helps to ensure the relevance and comprehensiveness of 
the information so identified, targetting it on specific 
decisions. In instructional development, such information 

is typically composed of student performance data-, time-to- 
criterion data, and development time and cost data. 

3. Identify sources of information . The tentative in- 
struments, channels, networks, and data systems are identified 
and matched with the decision matrix. A sizable number of 
sources has proved useful to RELATE at one time or another 
during its formulation ^(Fig. 8). Especially promising is 

the Student Data Management System, under development as a 
data bank feeding a large number of decisions concerning 
student entry into the program and placement within the units 
and modules. Also of interest isl'TRAC-COST, originally a com- 
puterized development cost analysis package prepared spe- 

_ * 

cifically for RELATE. Unfortunately, the. computerized 
version proved too complex, rigid, and costly to serve this 
type of a project well; TRAC-COST is now coupled with manual 
processing of the* data, but its essential design is proving 
very servicable. 



^Management literature has shown increasing interest 
in the problems of decision-making under conditions of 
uncertainty . Undoubtedly, such conditions characterize much 
of the development process, particularly during the early 
phases, but the models for this type of decision-making 
offered to date seem to be too expensive or otherwise un- 
suited to development as it is currently practiced. 
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Each data system, as it emerged, was targetted into the 
decision matrix (Fig. 9). In this way, relevance of the in- 
formation was ensured and the probability of its actual (not 
merely planned). use in making decisions was enhanced. 

4. Identify means of information processing . A broad 
distinction between two types of data is in order here. 
Quantifiable data are processable through customary routes 
(e.g., ledger sheets, unit record equipment, computers, etc.). 
More unwieldy are the non-quantifiable data, such as des- 
criptive statements, subjective opinion, and even intuition. 
Many management information system authorities have chosen to 
ignore this latter category, but a brief reflection on the 
nature of most development decisions will reveal that, given 
the present state of the art, they rely heavily upon non- 
quantitative but highly persuasive information. Forrester 
asserts that ,f we should rely less exclusively on statistics 
and formal data and make better use of our vast store of 
descriptive information." (5) The means of "processing" 
this type of information is not so apparent as, say, using 
a card sorter, but the adroit developer will frequently make 
use of devices such as thoughtfully planned agendas for team 
meetings or reports judiciously abstracted from tape-re- 
corded proceedings to structure the team's decision processes 
for optimum impact by these less rigorous kinds of data. 

It is encouraging that data collected across many devel- 
opment projects are highly similar in nature. This fact 
allows a development agency which has a number of projects 
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in progress at any given time to effect economies in infor- 
mation processing through the use of uniform procedures. 
Even though no computer may be involved, this arrangement 
can still be termed a "time-shared" one. The ID Department 
at Indiana has programmed SILA, a student data bank which 
can store data from several projects simultaneously and 
which was designed to transmit data fmm the bank to any 
one of several statistical routines. Technical problems have 
forced an overhaul of the package, but the basiz principle is 
an attractive one, promising greatly increased power in 
decision-making at little or no additional cost. 

5. Estimate cost . Experience will soon enable the 
neophyte developer to make reasonably reliable estimates of 
processing costs early in the life of the project. In actual 
practice, the developer will keep a sort of cental "running 
total" at each stage and will usually not be caught by a 
sudden realization that his information management system will 
consume, say, 2.S times the total project allocation. 

6. Curtail the design to match cost constraints . If 
the logic outlined so far has been closely applied, the 
design should already be "lean." The seemingly trivial act 
of targetting information to specific decisions should sig- 
nificantly reduce unwanted (and unwonted) data". Time-sharing 
capabilities will further increase the return on the invest- 
ment of meager resources. Even so, the design may yet be* 
too ambitious. Rank ordering of the information types-- 
with careful regard to the cost/gain ratio of each- -will 
permit sound paving of portions of the design until a feasible 
plan emerges. 
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7. Implement , The plan, in draft form, is ready to 
place into operation. In most cases, information management 
systems should be put into service incrementally. It 
requires time to identify the ultimately crucial types of 
data and to debug the operation. Gingerly testing the 
system part by part will help avoid casual ities and "system 
breaks, " and will be conducive to a climate of acceptance 

by team members, who may initially be wary of the whole 
thing . 

8. Revise as required . Revisions, either major or 
minor, will frequently be in order. Whether it is worthwhile 
to alter the formal design on paper, or merely to make the 
needed adjustments in practice, will depend on circumstances. 
Small scale, short term projects probably need few formal 
documents to begin with, and will probably require very 
little alteration in them. But as scale and complexity 
increases, alterations in information processing may need 
team ratification and elaborate reformulation of the stated 
design. In any event, the ultimate IMS design will 
gradually evolve, through successive approximations, in a 
way that parallels the development process itself. The 
developer, if at all temperamentally suited to his pro- 
fession, should find this a comfortable state of affairs. 
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